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ABSTRACT 


Current U.S. Navy combat system suites are ship class dependent. There are a 
variety of configurations that include sensors, weapons, and system interfaces to 
accomplish similar goals. The Navy Surface Warfare Center recommends developing 
combat system architectures utilizing reusable product line components. ‘This 
recommendation is accomplished by applying model-based systems engineering and 
product line engineering to develop a combat system architecture with planned reuse of 
system components. Current U.S. Navy and European combat systems are reviewed as an 
introduction to the architecture and components of operational systems. Conducting 
functional decomposition and identifying commonalities of the reviewed combat systems 
allow for development of a system architecture following the Hatley-Pirbhai modeling 
framework. The system architecture helps identify system variability, which, in turn, 1s 
used to generate orthogonal variability models that are used to design the combat system 
product line. A product line orthogonal variability model features packaged variants for 
three proposed combat system tiers representing scalable capabilities. The benefits of a 
product line engineering approach are validated by a system-level Constructive Product 
Line Investment Model. This research provides a methodology and cost modeling tool for 
future combat system design as well as background for further research in combat system 


product line engineering. 
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EXECUTIVE SUMMARY 


In 2017, the Chief of Naval Operations (CNO), ADM John Richardson, released 
“The Future Navy, A CNO White Paper.” Within this document, the CNO discussed the 
need for a 355-ship Navy using advanced technology, new types of ships, and new methods 
of employing these ships and technology. The CNO described the need for the future Navy 
to have the ability to operate in blue water, as well as the littorals, with adequate numbers 
of ships and capability to defeat enemy attacks. Additionally, ADM Richardson described 
unmanned systems as “an integral part of the future fleet” that are networked and 
“affordable to buy in large numbers” (Richardson 2017). The need for a large, 
technologically advanced future Navy, with unmanned systems, further emphasizes the 
utility of a combat-systems product line due to the capabilities overlap that occurs when 
designing combat systems for blue water and littoral missions. These capability overlaps 
lend themselves well to the product-line engineering concept of designing a system with 
the planned intent of reusing and modifying various components to allow for mass 
customization of products. Additionally, planned reuse of system components results in a 


greater return on investment for the combat system customer. 


Current U.S. Navy combat system suites are ship-class dependent. There are a 
variety of configurations that include sensors, weapons, and hardware/software 
integrations to accomplish similar goals. Aegis combat system is the integrated combat 
system of Ticonderoga-class guided missile cruisers and Arleigh Burke-class guided 
missile destroyers. Aegis’s development in the 1970s was not conducted with the concepts 
of product line engineering (PLE) or open architecture (OA) in mind. Ship Self-Defense 
System (SSDS) combat system development for aircraft carriers and amphibious warfare 
ships incorporated OA and systems thinking; however, the application and integration of 
the combat system was unique to the ship-class (DOT&E 2011, 171). The Zumwalt-class 
guided missile destroyer utilizes the Total Ship Computing Environment (TSCE), which 
integrates engineering and damage control automation systems along with the combat 
system (Henry, Iacovelli, and Thatcher 2009, 21-22). Zumwalt’s TSCE was also 


developed utilizing OA and systems engineering processes, but it is also ship-class specific 


XVI 


and is not designed for integration on other platforms. The LCS-class and future frigate 
variant (FFX) use an Aegis derived system called COMBATSS-21 (Lockheed Martin 
2017). Ship-class dependent combat system suites do not follow the Navy Surface Warfare 
Center’s (NSWC) vision for the “development of reusable product line components into a 


single combat system architecture” (Murphy, Richardson, and Sheehan 2013, 11-12). 


The disaggregated nature of current U.S. Navy combat systems is not optimal from 
a technical design nor from a cost perspective throughout the system’s life cycle. 
Employing a product line engineering approach to future combat system design is 
beneficial for both the combat system developer and the customer. Product line engineering 
concepts such as building once and the planned reuse of system components, helps the 
Navy achieve the overarching strategic guidance of the CNO as well as technical guidance 


from NSWC. 


This research explores the possibility of applying product line engineering and open 
architecture to develop a common system design for future Navy combat systems. Product 
line engineering and open architecture, including their application to combat system design 
are discussed in detail. A functional decomposition of current Navy combat system suites 
provides the framework for a product line incorporating the commonalities needed for 
effective combat capabilities regardless of platform or ship- class. The system architecture 
is used to integrate the commonalities into a functional system. Currently, no combat 
systems product line in the U.S. Navy exists. The benefits of PLE including cost savings 
and program continuity have not been realized by the Navy due to the current stovepipe 


arrangement of combat systems across multiple platforms. 


A robust engineering product line, focusing on the functional components of Navy 
combat system commonalities across multiple platforms is developed. Additionally, a 
product line strategy economic analysis is conducted utilizing the System Constructive 
Product Line Investment Model (COPLIMO). This includes parametric cost analysis of 
hardware and software architectural options for the combat systems. The representative 
results utilizing analogous, current Aegis combat system cost data suggest a strong return 


on investment (ROI) of a product line approach. 


XVIL1 


References 


Henry, Mark, Michael Iacovelli, and Jeffrey Thatcher. 2009. “DDG 1000 Engineering 
Control System (ECS).” In ASNE Intelligent Ship VIII Symposium. 20—21. 


Lockheed Martin. 2017. “Integrating the Aegis Derived COMBATSS-21.” Accessed 
August 7, 2017. http://www.lockheedmartin.com/us/news/features/20 16/1601 12- 
mst-integrating-the-aegis-derived-combatss-2 | -with-the-littoral-combat-ship.html 


Murphy, Alvin, David S. Richardson, and Terence Sheehan. 2013. “The Importance of 
System-of-Systems Integration” Leading Edge, February. Accessed August 9, 
2017. http://www.navsea.navy.mil/Portals/103/Documents/NSWC_Dahlgren/ 
LeadingEdge/CSEI/CombSys.pdf. 


The Office of the Director, Operational Test and Evaluation. 2011. DOT&E FY2011 
Annual Report, Ship Self-Defense. 171. 


Richardson, John, ADM USN. Chief of Naval Operations. 2017. “The Future Navy.” 
Accessed January 9, 2018. http://www.navy.mil/navydata/people/cno/Richardson/ 
Resource/TheFutureNavy.pdf. 


X1X 


THIS PAGE INTENTIONALLY LEFT BLANK 


XX 


ACKNOWLEDGMENTS 


I thank my advisor, John Green, for his subject matter expertise and valued 
mentorship throughout the thesis process. I thank my co-advisor, Dr. Ray Madachy, for his 
time and investment model contributions. I also thank my second reader, Dr. Douglas Van 
Bossuyt, for his time and effort reviewing my thesis. Lastly, I thank my wife for her support 


throughout this process. 


XX1 


THIS PAGE INTENTIONALLY LEFT BLANK 


XXll 


I. INTRODUCTION 


A. BACKGROUND 


Current U.S. Navy combat system suites are ship-class dependent. There are a 
variety of configurations that include sensors, weapons, and hardware/software 
integrations to accomplish similar goals. Aegis combat system is the integrated combat 
system of Ticonderoga-class guided missile cruisers and Arleigh Burke-class guided 
missile destroyers. Aegis’s development in the 1970s was not conducted with the concepts 
of product line engineering (PLE) or open architecture (OA) in mind. Ship Self-Defense 
System (SSDS) is the installed combat system on aircraft carriers and amphibious warfare 
ships (DOT&E 2011, 171). Ship Self-Defense System development incorporated OA and 
systems thinking, however, the application and integration of the combat system was 
unique to the ship-class. The Zumwalt-class guided missile destroyer utilizes the TSCE, 
which integrates engineering and damage control automation systems along with the 
combat system (Henry, Iacovelli, and Thatcher 2009, 21—22). Zumwalt’s TSCE was also 
developed utilizing OA and systems engineering processes, but it is also ship-class specific 
and is not designed for integration on other platforms. The LCS-class and future frigate 
variant (FFX) use an Aegis derived system called COMBATSS-21 (Lockheed Martin 
2017). Ship-class dependent combat system suites do not follow the Navy Surface Warfare 
Center’s (NSWC) vision for the “development of reusable product line components into a 


single combat system architecture” (Murphy, Richardson, and Sheehan 2013, 11-12). 


B. RESEARCH QUESTIONS 


The NSWC vision for the engineering product line methodology applied to combat 


system architecture results in the following research questions: 


l. Can PLE be used to develop a common system architecture design for 
future Navy combat systems instead of using unique, platform specific 


combat system suites? 


2. What common functional and physical features as part of the architecture 


are important aspects of developing a combat systems product line? 


a: How can a product line strategy economic analysis be conducted utilizing 
a system level parametric model for cost and return on investment analysis 


of product options for the combat system’? 


The first question is addressed by reviewing the components of current and past 
combat systems to provide the foundation for a common system architecture. Software 
product line engineering concepts are applied at the system level to conduct physical and 
functional analysis. The warfare capabilities are bounded to three tiers of combat systems. 
The first tier 1s designed for surface warfare (SUW) or intelligence, surveillance, and 
reconnaissance (ISR) missions. The second tier combat system provides cruise missile 
defense capability. Finally, the third tier is capable of theater ballistic missile defense 
(TBMD) and cruise missile defense. These tiered concepts are applicable to the broader 


problem of specific warfare areas addressed by combat systems. 


The second question 1s explained by conducting a functional analysis and allocation 
of current ship-class specific combat system suites to decompose the combat system into 
top level and lower level functions. Upon developing the system functional breakdown, 
common functions of the combat system are identified. These functions are used to develop 
a system architecture utilizing Hatley-Pirbhai modeling, including an enhanced data flow 
diagram (EDFD) and an architecture flow diagram (AFD). The system architecture is a 
tool to help identify system variability, which is related to variability subjects that 
correspond to variation points. Components defined as variation points provide the 
structure for orthogonal variability models (OVMs) which in turn be used to design the 
product line. An OVM with packaged variants representing the three warfare capability 


tiers describe the product line as a whole. 


The third question is answered by applying a system level adaptation of the 
Constructive Product Line Investment Model (COPLIMO) to conduct a cost analysis on 


the proposed combat systems architecture product line. The model called System 


COPLIMO is used to conduct an analysis of alternatives when comparing the combat 


systems product line to current one-off combat system suites. 


C. SPECIFIC CONTRIBUTIONS 


The author offers the following application of system architecture and modeling 
techniques as new contributions to the field of combat system design and engineering. The 
Hatley-Pirbhai architecture framework is used as a template for the detect, control, engage 
paradigm of combat system functionality. This is proposed as a standardized high level 
architectural form for combat system design. Applying software PLE techniques at the 
system level, to system components, is proposed as a best practice for identifying 
variability within the combat system. Using the Hatley-Pirbhai architectural models to 
develop orthogonal variability models (OVMs) is recommended to identify product line 
variants and associated variation points within the combat system architecture. The author 
offers that OVMs are a valid method of quantifying mission unique, adapted, and reused 


components as percentages for System COPLIMO. 


The architecture and modeling methods used in this thesis are accepted systems 
engineering techniques. However, the integrated model-based systems engineering 
(MBSE) methodology of Hatley-Pirbhai modeling, software PLE processes, and System 
COPLIMO is a distinct contribution to this subject matter. 


D. ORGANIZATION 


The thesis is organized into three main segments that address a literature review, 
methodology and approach, and conclusions including future work. Figure | is a flow 
diagram that depicts the segments, associated chapters, and thought process throughout the 
thesis. Chapters I and II give the background and need for a combat system product line. 
A review of current surface combatant combat systems, including U.S. Navy and European 


systems, introduces the reader to the architecture and components of operational systems. 


This review sets the stage for the modeling processes that the author proposes for 
developing a combat system product line. The process is illustrated in the Chapter III flow 


diagram section of Figure |. As discussed earlier, the modeling method begins with Hatley- 
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Pirbhai modeling, using the functional and physical components of current combat systems 
to propose a common combat system architecture. The enhanced data flow diagram is 
developed first, showing the functional components of the combat system. The functions 
in the EDFD are synthesized into physical components to produce the AFD, utilizing a 


common architecture template. 


The combat system AFD provides the model necessary for variation point 
identification and analysis. Variation point identification in the AFD 1s the first step in the 
orthogonal variability modeling process. Each variation point is decomposed into different 
variants that comprise the OVMs, these variation points and associated variants are 
described as requirements in the textual requirements step of orthogonal variability 
modeling. The textual requirements are then used to revise the Hatley-Pirbha1 AFD model 
in more detail by allocating components (variants) to each variation point. Next, the 
individual variation point OVMs are developed from the allocated AFD and related textual 
requirements. Packaged variants used to represent three tiers of combat system and 
constraint dependencies on the individual variation point OVMs create the product line 
OVM. This model displays the feasible combinations of packaged variants, variation 


points, and variants for the product line. 


The product line OVM is necessary for developing the inputs for System 
COPLIMO that completes the work presented in Chapter III. The System COMPLIMO 
requires identification of system components (variants) that are mission-unique, adapted, 
reused across products. These unique, modified, and common components are quantified 
in the System COPLIMO and are used to create an investment model that describes return 


on investment by using a product line engineering approach to combat system design. 


Chapter IV concludes the material presented by conducting a summary of analysis 
and presenting future work. The current surface combatant combat systems are revisited 
and the outcomes of the modeling techniques are recapped. The thesis 1s organized in such 
a manner that the reader can flow logically between topics and use Figure | to reference as 


necessary. 
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Figure 1. Thesis Organization Flow Diagram. 





EK. SUMMARY 


This research explores the possibility of applying product line engineering and open 
architecture to develop a common system design for future Navy combat systems. Product 
line engineering and open architecture, including their application to combat system design 
is discussed in detail. A functional decomposition of current Navy combat system suites 
provides the framework for a product line incorporating the commonalities needed for 
effective combat capabilities regardless of platform or ship-class. The system architecture 


is used to integrate the commonalities into a functional system. Currently, no combat 
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systems product line in the U.S. Navy exists. The benefits of PLE including cost savings 
and program continuity have not been realized by the Navy due to the current stovepipe 


arrangement of combat systems across multiple platforms. 


A robust engineering product line, focusing on the functional components of Navy 
combat system commonalities across multiple platforms is developed. Additionally, a 
product line strategy cost analysis is conducted utilizing System COPLIMO. This includes 
parametric cost analysis of hardware and software architectural options for the combat 
system. The representative results utilizing analogous current Aegis combat system cost 


data suggest a strong ROI of a product line approach. 


In the following chapter, a comprehensive literature review is conducted describing 
the concepts of PLE, OA, and COPLIMO. The literature review provides a brief history of 
current combat system suites including Aegis and SSDS. Additionally, a U.S. Navy air 
defense background is provided to focus the engineering product line to this specific 
warfare area. The literature review provides the evidence that demonstrates the need for a 


combat systems product line. 


I. LITERATURE REVIEW 


Developing an engineering product line for a future U.S. Navy combat system 
requires an understanding of the components and functions of current combat systems, 
operational at sea. Comparing different combat systems offerings allow for further analysis 
and development of a proposed combat system product line. A brief description of product 
line engineering, system architecture, and open architecture is necessary to understand the 
underlying framework of combat systems. The U.S. Navy combat systems reviewed 
include Aegis, SSDS Mk 1 and Mk 2, and COMBATSS. Additionally, European combat 
systems including Terma C-Series, SAAB 9LV, and Thales TACTICOS are analyzed to 
determine the necessary architectural functions, behaviors, and components for a product 


line. 


A. PRODUCT LINE ENGINEERING 


The term product line is derived from the production line, which was conceived by 
Ford as the most effective method of mass-producing automobiles. Prior to production 
lines, products were built specifically for individual customers. In this case, product 
customization is relatively easy since each product is built individually. Production lines 
allow manufactures to produce hardware or software, repetitively, for mass consumption 
by as many customers as the consumer market allows. Due to the larger number of products 
being produced in a production line, customization is more difficult, so the customer has 
fewer choices of hardware or software. Product lines introduce the concept of mass 
customization, which combines the mass output of a production line with the ability to 
customize hardware and software to the individual user’s needs (Pohl, B6ckle, and van der 


Linden 2005, 4). 


A more formal definition of a product line is, “‘a set of systems that share a common, 
managed set of features that satisfy the specific needs of a particular market segment or 
mission and that are developed from a common set of core assets in a prescribed way” 
(Guertin, Nicholas, and Clements 2010, 78). The technical work conducted to develop 


product lines is referred to as Product Line Engineering, “a well-established engineering 
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discipline that provides an efficient way to build and maintain portfolios of systems that 


share common features and capabilities” (Clements et al. 2014, 12). 


Department of Defense (DoD) systems developed with PLE have “demonstrated 
improvements in development time, cost, quality, and engineering productivity that 
consistently attain integer-multiple improvements over comparable non-PLE engineering 
efforts” (Clements et al. 2014, 12). In the Aegis combat system, “Lockheed Martin’s 
Maritime Systems and Sensors Division maintains the Common Product Line (CPL) 
requirements” which allows the product line to “develop once, and build and deploy many 
times from one set of common assets—principally requirements, source code, and tests.” 
(Clements et al., 2014, 15). An additional characteristic of the product line approach is 
“repeatable per-product cost savings of 50% to 67% to 90%” (Guertin, Nicholas, and 
Clements 2010, 87). Product line engineering is used in concert with open architecture in 


developing robust systems engineering solutions. 


B. SYSTEM ARCHITECTURE AND OPEN ARCHITECTURE 


A basic system architecture 1s the aggregate of system operational requirements, 
Support and maintenance model, defined technical performance measures (TPMs), and 
properly prioritizing the TPMs. The architecture includes top-level system configurations 
including operational interfaces, the environment in which the system is going to operate, 
and projected mission scenarios (Blanchard and Fabrycky 2001, 93). A functional 
architecture can be developed from the system architecture by conducting functional 
analysis to describe the system in terms of functionality. The system’s physical architecture 
is a further evolution of the functional architecture, developed by assigning physical 
components to the functions of the system that facilitate mission accomplishment 


(Blanchard and Fabrycky 2001, 93). 


System architecture is described as an open architecture if “the hardware and 
software interfaces are sufficiently well defined so that additional resources can be added 
to the system with little or no adjustment” (Buede 2009, 274). Successful system 
architectures are both proprietary and open, with the developer controlling system specific 


standards and protocols (Maier and Rechtin 2009). The open systems and open architecture 
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construct is what makes product line engineering achievable. The common core attributes 
of an engineering product line require open architecture in order to build, deploy, and 


evolve the system effectively over time. 


C. COMBAT SYSTEM DEVELOPMENT 
1. Aegis Combat System 


Aegis is the U.S. Navy’s air defense weapon system installed on Ticonderoga-class 
cruisers (CG) and Arleigh Burke-class destroyers (DDG), first operational at sea on the 
USS Ticonderoga (CG-47) in 1981 (Emch 1992, 50). The development of Aegis, which 
spanned over 20 years, began with the Advanced Surface Missile System (ASMS) and 
resulted in “the integration of the entire ship’s combat system and the design and 
construction of a completely system engineered and integrated ship” (Threston 2009, 85). 
Over the 30 plus year production of Aegis, its expandable and scalable system architecture 


has provided the flexibility to evolve and remain relevant (Threston 2009, 85). 


The primary function of Aegis is to integrate SPY-1 radar to control standard 
missiles (SM) to provide air defense from various threats including anti-ship cruise missiles 
(ASCM), ballistic missiles, aircraft, and other airborne threats. Aegis was designed and 
developed to “deal with long-range saturation attacks...and was the first weapon system to 
use missiles with commandable autopilots, which could be launched then guided into 
‘baskets’ near their targets without continuous radar illumination” (Friedman 2006, 104). 
Since the illuminators are only turned on when the fired missile is in close proximity to its 
target, the commandable autopilot allows each illuminator to share multiple missiles 
(Friedman 2006, 104). Additionally, Aegis was the first U.S. combat system with the 
ability to make doctrinal decisions, based on rules that can be changed onboard the ship, 
via software running on the command and decision (C&D) processor (Friedman 2006, 


104). 


The eight major elements of Aegis represented in Figure 2 are as follows (Threston 


2009, 89-91): 


l. AN/SPY-1A Phased Array Radar 


Z Mk-1 C&D System 

3, Mk-1 Aegis Display System (ADS) 

4. Mk-1 Weapons Control System (WCS) 

5; Mk-99 Fire Control System (FCS) 

6, Vertical Launching System (VLS) Mk-41 
ie Standard Missile Family 


8, Mk-1 Operational Readiness and Test System (ORTS) 





Figure 2. The Aegis Weapon System. Source: Threston (2009). 


On the Ticonderoga-class cruiser platform, the Aegis weapon system Mk 7 is 
designed “around the command and decision, system Mk 1, Aegis display system, and 


weapons control system Mk 1” (Friedman 2006, 104). The Arleigh Burke-class destroyer 
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platform is designed around “C&D Mk 2, Aegis display system Mk 2 (with two screens 
rather than four), and WCS Mk 8” (Friedman 2006, 104). Both CG and DDG platforms 
employ SPY-1 radar, which integrates both fire control and air search radar, allowing for 


very quick reaction times to air threats (Friedman 2006, 104). 


It is essential that Aegis have the ability to evolve in order to address continuously 
advancing threats and mission sets. The most significant upgrades to Aegis over its 30 year 
production run include integrating Mk-41 VLS, AN/SPY-1 B/D radar, AN/SPY-1 D (V) 
radar, computer and display upgrades, and various advances in missile technology 


(Threston 2009, 103-105). 


Installing Mk-41 VLS in place of the Mk-26 Dual Arm Launching System had the 
greatest impact of the other major upgrades. VLS enabled Aegis to “perform new missions, 
decreased system reaction time still further, increased the number of missiles that could be 
carried in the ship, and vastly improved mission reliability” (Threston 2009, 103). 
Additionally, VLS’s large number of launch cells allowed Aegis to carry Tomahawk, 
Standard Missile 2 Block IV, Standard Missile 3, Evolved Sea Sparrow Missiles (ESSM), 
and Standard Missile 6. 


The AN/SPY-1 B/D radar was developed as a redesign of the AN/SPY-1 phased 
array antenna, giving it greater resistance to electronic countermeasures (ECM) (Threston 
2009, 104). Along with the phased array antenna redesign, “the signal processor was 
redesigned to reduce processing losses, improve electronic counter-countermeasures 
(ECCM) performance, and greatly improve maintainability by introducing a number of 
automatic alignment features” (Threston 2009, 104). The AN/SPY-1 D (V) radar evolved 
from the B/D radar as stealth technology became more prevalent. The D(V) upgrades 
included “wave forms designed to reduce background clutter thereby increasing the 
potential for detecting the stealth target,” additional ECCM capabilities, and improved 
capabilities in the littorals (Threston 2009, 104). 


Computer and display upgrades have been necessary to fully utilize the capabilities 
of the upgraded radar and missile technologies. Aegis was introduced with Navy standard 


AN/UYK-7 computers and UYA-4 displays. The computing power and technological 
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limits of the AN/UKY-7 computers bounded what was achievable with the Aegis 
functional architecture. Aegis had to allocate functionality to three different AN/UKY-7 
computers, allocated to AN/SPY-1, C&D, and WCS. In this configuration, the AN/UKY- 
7 allocated to process the AN/SPY-1 data was overloaded, which required (repartitioned 
to) resources from the AN/UKY-7 allocated to C&D. Adjunct processors were added to 
the AN/UKY-7 computers to allow for upgrades in displays and radar doctrine, in 
anticipation of developing OA for Aegis.'! Adjunct processors took on additional processes 


identified for Aegis baseline upgrades, such as baselines 5.3 and 6.1. 


The computers were upgraded to the next generation of Navy standard AN/UY K- 
43/44, AN/UYQ-21 displays, and later, AN/UYQ-70 displays (Threston 2009, 104). A 
Navy policy change in the 1990s resulted in the use of commercial-off-the-shelf (COTS) 
computer equipment, to “reflect the best in current day computing technology” (Threston 
2009, 104). With the addition of COTS computers, Aegis evolved by “redesigning the 
computer programs to take advantage of the increased memory and computer 
computational power” (Threston 2009, 104). Open Architecture was also introduced to 


Aegis for the first time. 


The most recent development of the Aegis combat system is its integration and use 
as a TBDM platform, which is a block improvement program announced in 2003 
(Friedman 2006, 107). The ballistic missile defense (BMD) system for Aegis incorporates 
a high-powered discriminator (HPD) radar that “is a phased array with a relatively narrow 
field of view, trained toward the incoming missile warheads using SPY-1 data” (Friedman 
2006, 107). Aegis utilizes different SM missile variants as launch vehicles, with a 
Lightweight Exo-atmospheric Projectile (LEAP) to intercept ballistic targets. The LEAP 
includes a kinetic warhead (KW) with “a longwave infrared (IR) seeker and Solid- 
propellant Divert and Attitude Control System (SDACS)” which guides the KW to hit and 
kill the ballistic target (Landis 2001, 436). This ballistic missile defense capability was 


derived from Aegis’s original design for the anti-air warfare (AAW) mission. 


' John M. Green, interview by author, November 13, 2017. 
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Aegis’s ability to adapt and incorporate additional functionality has allowed it to 
remain the Navy’s most widely deployed and versatile air-defense weapon system over the 
past three decades. Aegis continues to evolve with emerging threats, new missions, and 


technological advancements. 


zis Ship Self-Defense System 


Ship Self-Defense System 1s the air defense combat system for non-Aegis ships that 
“integrates existing sensors and weapons using commercial-off-the-shelf components” to 
provide defense against ASCMs for ships operating within range of these missiles (Whitely 
2001, 516). SSDS Mk 1 was designed “for the LHD 1, LSD 41, LSD 49, and LPD 17 
classes” of amphibious assault ships (Friedman 2006, 123). Mk | later evolved into SSDS 
Mk 2, which was designed for CVN class aircraft carriers and was installed on LPD 17, 
LHD 8, and LHA 6 class amphibious ships (DOT&E 2012, 203). 


The fundamental performance requirement for both SSDS Mk 1 and Mk 2 is raid 
annihilation, described by the “probability of raid annihilation Pra against a range of 
potential threats” (Whitley 2001, 520). This probability of raid annihilation requirement 
drove the argument “that integrated ship defense systems must have open, distributed 
architecture designs” (Prengaman, Wetzlar, and Bailey 2001, 523). The SSDS architecture 
permits weapon and sensor integration that support meeting the Pra requirement against 
ASCMs (Prengaman, Wetzlar, and Bailey 2001, 523). The “system was developed to 


support sensor fusion using dissimilar sensors” (Friedman 2006, 124). 


SSDS Mk I employs the detect, control, and engage principle for self-defense. The 
sensors utilized for target detection include Phalanx close-in weapon system (CWIS), 
AN/SPS-67 surface search radar, AN/SLQ-32 ECM system, and AN/SPS-49 air search 
radar. The tactical control data system requires three operators, working between five 
operator consoles, and two large screen displays. Engagement capabilities are performed 
by rolling airframe missiles (RAM), Phalanx CWIS, and electronic countermeasures. 
SSDS Mk 1 utilizes an Aegis style doctrine that allows for automatic engagement of targets 
via weapons and sensor interactions (Friedman 2006, 124). A fiber-optic local area network 


(LAN) connects the ship’s sensors, control system, and weapons giving SSDS the 
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capability to integrate system data to form target tracks (Friedman 2006, 122). The LSD 
41/49 SSDS configuration is shown in Figure 3. 


ee 


a. 





Figure 3. LSD 41/49 SSDS Mk1 Configuration. 
Source: Norcutt (2001). 


The SSDS network, shown in Figure 4, is configured as “a dual home star topology 
incorporating network hubs that are positioned in different regions of the ship” (Norcutt 
2001, 543). This network configuration allows for efficient troubleshooting, effective 
COTS upgradability, simplified network reconfigurability, as well as decentralization for 
improved survibability (Norcutt 2001, 543). The system “software runs under a UNIX 
operating system, and it uses virtual machine environment (VME)-card computers linked 
by a FDDI bus” (Friedman 2006, 123). UNIX is a standardized COTS computer operating 
system with an open source framework (The Open Group 2018). The UNIX system 
operates on VWME-card computers, which provide data processing and control 


computational power. The standard for data transfer between systems over the LAN 1s the 
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fiber-distributed data interface (FDDI). Instead of using Ethernet cables, “glass fiber for 
data transfer was selected for its performance, low weight, and low electromagnetic 


susceptibility” (Norcutt 2001, 543). 





Figure 4. SSDS Double Star Topology Network Configuration. 
Source: Norcutt (2001). 


During the implementation of SSDS Mk 1, technological advancements in 
computing power and sensors development created potential for a more capable self- 
defense combat system utilizing the basic SSDS architecture. The evolution of SSDS Mk 
1 was driven by the need to integrate RAM, the NATO Seasparrow Surface Missile System 
(NSSMS), as well as the cooperative engagement capability (CEC) into a combat system 
designed for CVN ship-classes (Thomas et al. 2001, 547). The weapons and command and 
control integration resulted in the development of SSDS Mk 2 which “includes new 
functions such as remote sensor cueing (CEC) and ESSM control (in addition to RAM and 
CIWS)” (Friedman 2006, 124). The number of system interfaces increased from seven for 
SSDS Mk 1 to a total of 16 interfaces for SSDS Mk 2, as shown in Figure 5. These 
interfaces include, “radars (SPS-48 and -49, SPQ-9, SPS-67), the ship’s ASW system (CV- 
TSC), IFF, CEC, GCCS-M, data links (Links 4A, 11, 16), SGS/AC (gridlock/auto- 
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correlate), ESM (SLQ-32), weapons (Sea Sparrow, RAM), air traffic control radar (via 
TPX-42), and the integrated battle force trainer (BFIT)” (Friedman 2006, 124). This 
increase of system interfaces and complexity in SSDS Mk 2 resulted in 24 operators needed 
for the combat system, up from three operators needed for SSDS Mk 1. Additionally, 
system software transitioned from CMS-2 language in Mk | for C and C++, representing 


a shift to open source software standards (Friedman 2006, 124). 
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Figure 5. SSDS Mk 2 System Interface Configuration. 
Source: Thomas et al. (2001). 


CEC allows for “remote sensor cueing...of a local by a remote sensor” (Friedman 
2006, 124). That is, SSDS Mk 2 can receive track data, from a non-organic sensor on a 
platform with CEC, or the remote sensor cueing can work in the reverse manner, where 
SSDS Mk 2 transmits track data, from an SSDS organic sensor to a non-organic platform 
with CEC. The “primary role of CEC is inter- and intra-platform netting of long-range 
surveillance sensors” such as “AN/SPY-1, AN/SPS-49 and AN/SPS-48 radars” (Thomas 
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et al. 2001, 547). In order to conduct engagements with SSDS Mk 2’s own weapons via 
CEC, the following integration between SSDS and CEC was developed. CEC provides 
tracks, “sensors measurements associated with each track (Associated Measurement 
Reports or AMRs) of interest, and statistics for false tracks / engagement control” (Thomas 
et al. 2001, 547). The AMRs provided by CEC are then processed and filtered by SSDS in 
order to determine if the engagement is valid or false based on the CEC provided statistics. 
This “interface between SSDS and CEC is a high-fidelity interface that transfers composite 
track, identification (ID), engagement, sensor measurement, and control data between CEC 
and SSDS” (Thomas et al. 2001, 547). The SSDS Mk 2 engagement then takes place 
utilizing the CEC track and SSDS’s organic weapons, NSSMS and RAM. The integration 
of NSSMS with RAM and SSDS “supports multiple engagements, improved CEC track 
continuity, and improved resistance to degradation” (Thomas et al. 2001, 547). SSDS Mk 
2 continues Mk 1’s use of Aegis style doctrinal decision making for automatic engagement 
of targets. There is a supplementary weapon assignment function that “refers to the ship’s 
aircraft and to weapons in the accompanying ships of the battle group” (Friedman 2006, 
124). The expansion of SSDS to include additional engagement, weapons, and sensors 
capabilities is a result of its design as a collection of these systems, rather than designed as 


a complete combat system. 


3. Component Based Total Ship System (COMBATSS-21) 


COMBATSS is a shipboard combat system using COTS technology, that was 
“developed and tested at-sea an open architecture, “plug-and-play,’ component-based 
combat system” (Ukrainsky, Orest, and Nix 1998, 3). The system was designed as a 
scalable combat system based on the Aegis functional structure, that could be adapted to 
different ship platforms and mission sets based on using component based software. It 
“maximizes the use of commercially available hardware and software to produce a combat 
system suitable for installation in vessels both as small as patrol boats and as large as or 
larger than destroyers” (Ukrainsky, Orest, and Nix 1998, 4). Currently, COMBATSS is 
operational on the Littoral Combat Ship (LCS) Freedom-class as well as on ships of 
multiple international navies. It is fully network enabled to operate in battle groups and 


joint operations (Lockheed Martin Corporation 2010, 4). 
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Similar to SSDS, COMBATSS uses a modular approach to combat systems design 


with subsystems providing various sub functions within the overall COMBATSS Combat 


Management System (CMS). Figure 6 depicts the various subsystems that make up 
COMBATSS, including: 


Ey 


Electro-optics 


. Gun 


Tracking radar 

Surface missiles 

Bridge system 

Training simulation system 
Chaff launcher 


Electronic support measures (ESM) 


. Optical sight 

. Data links 

. Search radar 

. Identify friend or foe (IFF) antenna 


. Message system 


An example of the modular design is shown by the Gun Fire Control System 


(GFCS), which is a subsystem of COMBATSS. The electro-optics, gun, and tracking radar 


that make up the GFCS can operate either as peripheral systems integrated into 


COMBATSS or as individual, self-sufficient subsystems (Ukrainsky, Orest, and Nix 1998, 


4). The other subsystems follow this same approach to systems integration, which “enables 


quick and cost effective integration of various sensors and weapon systems into one 


coherent CMS” (Ukrainsky, Orest, and Nix 1998, 4). Where SSDS and COMBATISS differ 
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in the design approach, is COMBATSS planned reuse of software within a scalable 


component framework (Lockheed Martin Corporation 2010, 4). 





Figure 6. COMBATSS Combat Management System. Source: 
Ukrainsky, Orest and Nix (1998). 


Within the CMS framework of COMBATSS, the software components are divided 
into four major groups; track management, weapons control, missions, and navigation 
(Ukrainsky, Orest, and Nix 1998, 6). Depending on the platform application, the CMS can 
use any combination of these major software groups (Ukrainsky, Orest, and Nix 1998, 7). 
Each software group includes a collection of components that are defined within the CMS 
framework and receive data inputs from the COMBATSS subsystems. Various sensors and 
weapons can be introduced into the combat system since all the software components look 
the same once they are entered into COMBATSS CMS. This allows for rapid upgrades as 
more sophisticated weapons and sensors are developed (Ukrainsky, Orest, and Nix 1998, 


6). 
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The track management group components define “system tracks, local tracks, a 
track repository, a correlator, and an identifier” (Ukrainsky, Orest, and Nix, 6). Data inputs 
are received from radars, datalinks, and the electronic warfare subsystem (Ukrainsky, 
Orest, and Nix, 6). The mission group components define the logic that allows the 
accomplishment of specific mission sets with operator interaction. “An example mission 
coordinator is an anti-air warfare defense mission coordinator capable of coordinating 
multiple engagements, with different weapons, against a single or multiple targets” 


(Ukrainsky, Orest, and Nix, 6). 


The navigation group of components define “ownship location, compass, log, 
heading control, drive control, and navigator components” (Ukrainsky, Orest, and Nix, 6). 
Data from ownship location includes “current position and kinematics of ownship as 
reported by a shipboard device, usually a GPS” (Ukrainsky, Orest, and Nix, 6). The 
compass, log, heading control, and drive control data are standardized outputs from 
shipboard sensors. The navigator component uses these data outputs to predict ownship 


location on a given voyage plan (Ukrainsky and Nix, 6). 


Similarly, the weapons control group components define “engagement coordinator, 
weapon model, and weapon selector” (Ukrainsky and Nix, 6). The engagement coordinator 
component can provide planning, scheduling, and engagement execution orders within the 
CMS to order a specific weapons system, such as GFCS or missiles, to engage a target. 
The weapon model component creates a model for the weapons integrated into a specific 
COMBATSS platform. This model could be for gun systems or missile systems and it 
“provides the engagability calculations of the specific weapon” (Ukrainsky and Nix, 6). 
The weapon selector component provides operator support for selecting the most suitable 
weapon for the planned engagement. COMBATSS evolved from the Aegis combat system 
architecture to include planned use of COTS components with an open architecture 


concept. 


4. European Combat Systems 


When discussing product line engineering and combat systems, it is important to 


examine European naval combat systems. Terma, SAAB, and Thales all have combat 
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system offerings that follow the product line methodology. Terma’s combat system 
offerings feature the C-series product suite, based on a command and control (C2) system 
that can be combined with a range of modules that support various missions (Terma 2012}). 
SAAB’S 9LV combat system suite is a product line designed for various types of vessels, 
that support multiple missions through three different combat system packages, the 9LV 
Combat System (CS), 9LV Combat Management System, and the 9LV Fire Control 
System (SAAB 2015, 2). Thales’s TACTICOS is a combat management system based on 
open, scalable, modular architecture that can perform multiple missions on various types 


of vessels (Thales 2017). 


a. Terma C-Series 


Terma’s C-Series combat system suite is a product line that includes different 
mission modules that “are proven both as stand-alone and as an integrated system” (Terma 
2012}). The product line provides Electro-Optical Fire Control, 2D Air and Surface 
Surveillance radar, and data link, designed for amphibious ships, frigates, command ships, 
as well as smaller offshore patrol and patrol vessels. The C-series product line includes the 


following modules depicted in Figure 7 (Terma 2012d): 


1. C-Flex Naval C2 System 

2. C-Fire EO 

3. C-Search Naval Radar and IFF System 
4. C-Link Naval Link System 

5. C-Guard Naval Decoy System 


6. C-Sim Naval Simulation 
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Figure 7. C-Series - Maritime and Naval System Suite. 
Source: Terma (2012d). 


The C-Flex Naval C2 System is a modular, scalable command and control system 
that provides the integration and user interfaces for the C-series products listed above 
(Terma 2016a). The C-Flex system integrates data from ownship sensors, radars, weapons, 
external communications, and electronic support measure systems. This data plotted as 
tracks “on top of an Electronic Chart Display and Information System (ECDIS) / sea 
chart together with radar video” (Terma 2012b). The system is scalable to allow for 
between one and 24 operators and Operator Consoles, based on the application. C-Flex 
uses COTS hardware and software such as Microsoft Windows and Linux operating 
systems. The core C-series software is separate from the operating system, which allows 
for adding and removing sensors and weapon systems as required (Terma 2012b). Terma 
also provides the C-Search Naval Radar and IFF System that integrates into the C-Flex 
System. The naval radars include the SCANTER 6000 series, 4000 series, and 2600 series 


radars for various applications (Terma 20121). 
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The C-Fire EO system includes the COMPACT All Weather Gun Control System 
and the COMPACT Electro-Optical Gun Control System. The COMPACT All Weather 
Gun Control System “provides a standalone Fire-Control System with a combined Radar 
& Electro-Optical (EO) Director, Ballistic Predictor & Interface of one Naval Gun and an 
Operator Console for controlling any in-service naval gun,” from 30-127mm (Terma 
2012f, 1). The COMPACT Electro-Optical Gun Control System “provides a standalone 
Fire-Control System with an EO Director, Ballistics Prediction and Interface of one Naval 
Gun and an Operator Console for controlling any in-service naval gun,” from 30—76mm 
(Terma 2012g, 1). The C-Fire EO system can provide gun fire control for as many as three 
gun mounts and provide firing solutions for AAW, SUW, and naval gunfire support 
missions (Terma 2012a). The C-Fire system is designed to be fully integrated with the F- 
Flex command and control (C2) system and can be operated from any of the C-Flex 
Operator Consoles (Terma 2012a). Additionally, the C-Fire EO system offers add on 
options to the existing product. These options include software modules such as a 
surveillance software for the C-Flex system (Terma 2012f, 2). Figure 8 depicts the 
integrated system architecture of the COMPACT All Weather Gun Control System, the 
COMPACT EO Gun Control System follows the same configuration. 
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Figure 8. COMPACT AII Weather Gun Control System. 
Source: Terma (2012f). 
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The C-Link Naval Link System provides tactical data link capabilities that is 
supported by and integrated as an application within the C-Flex command and control 
system. C-Link can be used on different platforms, including ships, fixed and rotary wing 
aircraft, and land based applications to support various missions. C-Link supports the 
NATO tactical data links (TDLs) including, Link-11, Link-16, Link-22, and JREAP C. For 
non-NATO nations, Terma offers its own TDL as part of the C-Link system, called Link T 
(Terma 2012c). Link T is “based on the NATO Link 16 data model and protected by 
advanced commercial SW [software] encryption” (Terma 2012h, 1). Figure 9 depicts the 
system architecture of the COMPACT Link T Data Link System integrated into the C- 


series product line. 
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Figure 9. COMPACT Link T Data Link System. 
Source: Terma (2012h). 


The C-Sim Naval Simulation is a Naval Tactical Simulator (NTS) based on COTS 
products that fully integrates with the C-Flex command and control system. C-Sim creates 
a virtual battle space with “simulated entities and live tracks, radar emissions, IFF, AIS, 
TDL, communication, and environmental conditions” (Terma 2012e). This allows for 


realistic operator training on ownship and shore based facilities utilizing the C-series 
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combat system products. The training can be scaled from a single ship, single console 


configuration, up to multi ship, 20+ console configurations (Terma 2012e). 


The C-Guard Naval Decoy System is a decoy launching system that 1s designed to 
counter various missiles and torpedoes. C-Guard’s expandable architecture allows it to 
control from 6 to 24, standard NATO 130mm firing tubes. The system can be controlled 
locally by touch screen, from the C-Flex command and control system, or other combat 


management systems that the user chooses to integrate with C-Guard (Terma 2016b). 


b. SAAB 9LV 


SAAB 9LV is a modular combat systems product line that includes the combat 
system, combat management system, and fire control system for both surface and 
subsurface applications (SAAB 2015, 15). The 9LV Mk 3E (enhanced) series was SAAB’s 
first offering of the 9LV combat system utilizing COTS products. The Mk 3E uses COTS 
flat screen displays, a standard fiber distributed data interface to transmit data on the local 
area network, and Windows based multi-media interface (MMI) at the operator consoles 
(Friedman 2006, 91). Software for 9LV “is written in ADA, an object-oriented 
[programming] language specifically adapted to such modular applications” (Friedman 


2006, 92). 


l. 9LV100 Mk 3, for small ship or fire control systems with optical sensors 
2. 9LV200 Mk 3, for fast attack craft with radar 

2: 9LV300 Mk 3, for fast attack craft with optical sensors 

4. 9LV400 Mk 3, for larger warships 


OLV is currently in the Mk 4 series that has the ability to be scaled for coast guard, 
military combat boats, patrol vessels, large surface combatants, and submarines. 9LV Mk 
4 CMS is fully integrated with the 9LV FCS and can automate threat evaluation, 
engagement planning, and weapons control. 9LV CMS and FCS provide the ability to 
conduct multiple missions utilizing various gun configurations and surface to air missiles 


(SAMs) (SAAB 2015, 8). 


2) 


Figure 10 depicts the 9LV Mk 4 CMS on a surface combatant with various 
hardware modules (weapons, sensors, antennas) that can be provided by third parties and 


integrated into 9LV’s open architecture. 
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Figure 10. SAAB 9LV CMS Integration. Source: SAAB (2015). 


Cc. Thales TACTICOS 


Thales TACTICOS is an integrated, automated, CMS designed for surface 
combatants that can be implemented across multiple warfare areas. It is a scalable, modular 
system that includes open architecture and a data distribution service (DDS) system called 
OpenSplice, which allows the CMS to share real time data to the various applications of 
the combat system (Thales 2014, 2). TACTICOS runs a single architecture with a common 
hardware platform to integrate sensor and weapons for various mission requirements. 
Thales calls these mission requirements “Mission Solutions,” and the missions TACTICOS 
can perform range from littoral security operations to theater ballistic missile defense. 
Similar to SAAB, Thales designates products for different mission solutions as follows 


(Thales 2014, 6): 


l. MS-100, for littoral security operations 


2. MS-150, for ocean security operations 
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2 MS-300, for low intensity naval operations 


4. MS-400, for medium intensity naval operations 
>: MS-500, for high intensity naval operations 
6, MS-1000, for high intensity naval operations with theater ballistic missile 


defense capability 


The capabilities for mission solutions MS-300 through MS-1000 are as follows 
(Thales 2014, 6): 


l. MS-300, provides point defense with guns and littoral security 


Zi MS-400, provides point defense with guns and missiles, point defense 


with guns, ocean security, and littoral security 
a MS-500, provides wide area defense added to the capabilities of MS-400 


4. MS-1000, provides ballistic missile defense added to the capabilities of 
MS-500 


The data distribution service within the networked CMS is a “standards-based 
[quality of service] QOS-enabled data-centric middleware platform that enables 
applications to communicate by publishing information they have and subscribing to 
information they need in a timely manner” (Schmidt, Corsaro, and Hag 2008, 24). DDS 
allows the information model for the CMS to be properly implemented at the beginning of 
the system design and it provides the information framework with fault tolerance for each 
application (Schmidt, Corsaro, and Hag 2008, 28). It is important to note that “DDS has 
been mandated by the U.S. Navy’s Open Architecture Computing Environment as the 
standard publish/subscribe technology to use in next-generation combat management 


systems” (Schmidt, Corsaro, and Hag 2008, 28). 


European combat systems from Terma, SAAB, and Thales utilize a different 
paradigm than U.S. Navy combat systems. The six components of Terma’s C-series combat 


system suite are modular, designed for interoperability with third party sensors, weapons, 
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as well as other hardware and software components. The SAAB 9LV combat system is 
explicitly a product line, with scalable offerings of the same core architecture for various 
applications. Thales TACTICOS follows a similar design framework to 9LV and includes 
scalable combat system platforms for different applications based on the amount of 


functionality and features needed for a specific platform. 


D. SUMMARY 


Navy combat systems are systems of subsystems, or system of systems (SOS), that 
perform various functions to facilitate mission tasks and accomplishment. The architecture 
of a combat system must allow for interoperability between all subsystems. An 
understanding of system architecture and open architecture is required to decompose the 
means of subsystem interoperability to perform the combat system mission tasks. 
Describing the components and functions of the various combat system offerings from both 


the U.S. and Europe provides insight into combat system design. 


Aegis was designed as a complete combat system. Its functional architecture allows 
for upgrades as technology advances. This upgradability has been proven with the 
introduction of Mk-41 VLS, SPY radar upgrades, modern COTS computer integration, 
BMD capabilities, and increased functionality via baseline improvements. SSDS Mk 1 was 
designed as a collection of existing weapons and sensor systems including RAM, CWIS, 
AN/SPS-67 and AN/SPS-49 radars, and AN/SLQ-32 ECM. These existing hardware 
platforms were integrated as subsystems into the SSDS Mk I via software package, with 
capabilities limited by the existing weapons and sensor systems. SSDS Mk 2 further 
evolved the Mk | system by integrating existing weapons and sensors with increased 
capability. NSSMS and SPS-48 radar allowed for greater detect and engagement ranges. 
CEC provided Mk 2 the ability to detect and engage targets from other platforms such as 
DDGs with greater combat systems capability. Also, Mk 2’s introduction of C and C++ 
open source software signaled a trend towards open architecture concepts within combat 
systems design. COMBATTS’s scalable, modular, open architecture utilizes all of these 
concepts yet is not a true engineering product line. The European combat systems offerings 


including the C-series, 9LV, and TACTICOS are true engineering product lines. These 
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products offer scalable, modular, open architecture explicitly designed for various missions 


and platforms. 


Future U.S. Navy combat systems would improve several ways with a focus on 
product line engineering. The product line’s common, core set of features that are managed 
to meet the needs of a mission make the product line concept an excellent fit for the system 
of systems that 1s a combat system. Developing the products and core software once, with 
the plan to reuse it multiple times, on different applications, needs to be a design philosophy 
that occurs from the earliest stage of future combat system design. The future result of 
implementing product line engineering in combat system design is greater engineering 


productivity, faster development time, better quality products, and reduced cost. 
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Hl. METHODOLOGY AND APPROACH 


Development of the combat system product line architecture utilized Hatley— 
Pirbhai and orthogonal variability model modeling techniques to capture variability points 
within the combat system that define the product line. The scope of the proposed product 
line includes products for surface ship-based combat system scaled to three tiers as shown 
in Figure 11. The first tier includes a SUW capability designed for a small surface 
combatant, on the order of magnitude of a patrol type vessel, with the potential for fully 
unmanned capabilities focused on ISR. The second tier is designed around a cruise missile 
defense capability that could be employed on a future frigate (FFGX), amphibious assault 
ship, and aircraft carrier (CVN) platforms. The third includes theater ballistic missile 
defense and cruise missile defense capabilities, designed to facilitate the needs of a future 
guided missile destroyer (DDGX) and guided missile cruiser (CGX). Each tier of the 


product line captures the detect, control, engage paradigm. 


3rd Tier 


2nd Tier 


ist Tier 


SUW /ISR 
(Patrol, Manned / 
Unmanned) 


Cruise Missile Defense 
(FFGX, CVN, Amphib) 


TBMD + Cruise Missile Defense 


(DDGX, CGX) 


Figure 11. Combat System Product Line Three Tier Nested Relationship 
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The System COPLIMO 1s applied as a method of conducting product line life-cycle 
cost estimations. It includes “a product line development cost model and an annualized 
post-development life cycle extended at the system level (Boehm, Barry, et al., 2004, 1)” 
with defined input parameters, algorithms, and outputs. This model helps validate the 
benefits of creating a combat system product line. Although this analysis is conducted on 
the proposed combat system product line’s focused mission areas, the same concepts could 
be applied to incorporate anti-submarine warfare (ASW), electronic warfare (EW), cyber 


wartare, and other mission areas. 


A. SYSTEM ARCHITECTURE 


The combat system functional architecture is an adaptation of MHorner’s 
architectural functional model, emphasizing detect, control, and engage paradigm as the 
primary combat system functions (Horner 1999, 192). The functional architecture was 
refined using the Aegis top-level functional flow model (Navy 1989). The system functions 
were further developed with concepts from the FORCEnet Open Architecture Warfare 
System Domain Functional Architecture developed by the CNO Strategic Studies Group 
and outlined in the “FORCEnet Implementation Strategy” (National Academies Press 
2005, 128). Each function utilizes open architecture constructs in order to provide the 


foundation for a combat system product line. The proposed combat system functions are 


as follows: 
l. Sense 
oa Coordinate Mission 


2: Engage Target 
4. Provide Data / Information Services 
=e Assess Engagement 


In order to develop a combat system product line from the proposed combat system 
functions, the Hatley-Pirbhai methodology was used to develop a system architecture that 


can be translated to identify variation points and variability within the architectural model. 
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The Hatley-Pirbhai methodology utilizes graphical notation to separate the system’s 
functional and physical attributes into requirements and architectural models. The 
architecture template, as shown in Figure 12, is utilized to develop data flow diagrams and 
architecture flow diagrams. This template includes input processing, output processing, 
main functions or core processing, user interface processing, and support functions. An 
EDEFD shows the functional boundaries and interfaces of the system. System functions or 
“processes” are represented as labeled circles and the arrows connecting the functions show 
data flow. Parallel lines divide the model into stores that represent the functional 
boundaries between the different functions. Each function converts data inputs into outputs 


(Haggerty and Haggerty 2015). 


USER INTERFACE PROCESSING 


MAIN FUNCTIONS 


INPUT (CORE PROCESSING) 
PROCESSING PROCESSING 


OUTPUT 


SUPPORT FUNCTIONS 





Figure 12. The Architecture Template. Adapted from Hatley, 
Hruschka, and Pirbhai (2000). 


The EDFD provides the functionality to partition the system into physical entities 
represented in the AFD. The physical entities, also known as architecture modules can be 
systems, subsystems, or components of the physical system. Arrows indicate information 
transfer between physical entities and the functional boundaries are represented in the same 
manner as the EDFD. Further decomposition of the AFD results in component allocation 
to the architecture modules (Haggerty and Haggerty 2015). For the purpose of this thesis, 
component allocation includes two levels of the physical hierarchy. The top-level physical 
components are derived from the top-level system functions and the second level system 


physical components are decompositions of the top-level components. Top-level 
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components are numbered from 1.0 to N.O, second level components are numbered from 
N.1 to N.n, third-level components are numbered N.n.1 to N.n.n, and so on. The hierarchy 
numbering convention continues in the same manner for lower levels. The top-level 
component 1.0, decomposed into the second level is shown in Figure 13, adapted from 


Blanchard and Fabrycky (Blanchard and Fabrycky 2011, 87). 


Top Level 


Second Level 





Figure 13. System Physical Hierarchy Numbering Convention 


B. SYSTEM VARIABILITY 


The combat system functional and physical architectures provide the construct for 
identifying variability subjects within the combat system. Variability subjects are variable 
items within the system architecture. These variability subjects correspond with the 
variation points within the product line. The variation points each have different variants 
that are a representation of a variability subject. There are three steps necessary to create 
valid variation points and variants for the product line. The first step is to identify the 
variability subjects as discussed above. The second step is to define the variation point 
based on the real world variability helped determined by the system architecture. This 
variation point definition indicates that the product line has to support different types of 
variants, without explicitly stating each one. The third step is to identify variants of the 


variation point that supplement the information of the variation point. 


Variants of any given variation point may change over time based on advances in 
technology or fiscal environments, however, variation points usually remain constant 


throughout the life cycle of the system. Variability 1s modeled into the product line to allow 
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for customization by reuse of predefined objects, either functional or physical (Pohl, 


Bockle, and van der Linden 2005, 63-64). 


An OVM uses graphic notation to display the variability within a product line. The 
two classes within the OVM are the variation point and variant. Variability dependencies 
show the association between the variation point and variant classes. Variation points offers 


certain variants that must follow the following associative conditions: 


l. Each variation point must be associated with at least one variant. 

p72 Each variant must be associated with at least one variation point. 

ae A variation point can offer more than one variant. 

4. A variant can be associated with different variation points (Pohl, Bockle, 


and van der Linden 2005, 76). 


The conditions above are explicitly stated in Pohl, Bockle, and van der Linden’s 
Software Product Line Engineering, Foundations, Principles, and Techniques. Once 
variation points are defined as textual requirements, variants are assigned to them as textual 
requirements. Variability constraints are added to the OVM, which describe the 
relationships between different variants and variation points. These relationships, known 
as constraint dependencies, allow for the modeling of variants and variation points either 
requiring or excluding each other in the OVM. Each variant for a given variation point is 
shown as an alternative choice which takes a minimum and maximum value based on the 
number of variants for its associated variation point (Pohl, Bockle, and van der Linden 


2005, 82). 


Graphic notation for displaying variability within the proposed combat system 
architecture employ the Halmans and Pohl notation as shown in Figure 14. Developing 
OVMs for the system combine various aspects of this notation to show variability, 
relationships, dependencies, and constraints. Complex variability models can use grouping 
or packaging in the form of packaged variants to show relationships between variation 
points and variants. A packaged variant serves as a variation point that has associated 


constraint dependencies. This helps reduce OVM complexity in systems such as combat 
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systems, with numerous variation points and associated variants. When developed 
properly, OVMs provide a clear and concise method of communicating product lines to the 


customer (Pohl, Béckle, and van der Linden 2005, 87-88). 
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Figure 14. Orthogonal Variability Model Graphical Notation. Source: 
Pohl, Bockle, and van der Linden (2005, 82). 


C. SYSTEM MODELING TECHNIQUE 
1. Combat System Enhanced Data Flow Diagram 


The EDFD in Figure 15 was developed from the proposed combat system functions 
discussed earlier in this chapter. Hatley-Pirbhai modeling techniques and the architecture 
template provide a framework for the detect, control, engage paradigm that describes the 
overarching behavior of the combat system. The ovals labeled 1.0 Sense, 2.0 Coordinate 
Mission, 3.0 Engage Target, 4.0 Provide Data / Information Services, and 5.0 Assess 
Engagement are the five combat system functions. The arrows show the flow of data 


between functions as well as between the combat system and the external environment. 


Each individual contact (Ci though Cy) external to the combat system, enters the 
system via the Sense function. The Sense function transmits signals to the external 
environment and receives a signal internal to the combat system if a contact is detected. 


This occurs in the input processing partition of the architecture template. Contact data from 
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the Sense function flows to the Coordinate Mission and Provide Data / Information 


Services functions. 


The Coordinate Mission function is within the core processing area of the 
architecture template as it also receives tactical data from the Provide Data / Information 
Services function, a target engaged verification from the Engage Target function, as well 
as a kill assessment from the Assess Engagement function. Additionally, the Coordinate 
Mission function provides target classification and weapons scheduling data to the Engage 


Target function. 


The output processing partition of the architecture template houses the Engage 
Target function and the Assess Engagement function. Weapons link data is provided by 
the Engage Target function to the individual kills (Ki through Kn), external to the combat 
system. Similar to the Sense function, the Assess Engagement function transmits and 
receives signals to the individual kills to provide a kill assessment or determine if the target 


needs to be re-engaged. 


The Provide Data / Information Services function resides within the support 
functions area of the architecture template. In addition to receiving contact data from the 
Sense function, it transmits and receives track data to external entities and provides tactical 
data to the Coordinate Mission Function. The human system interface (HSI) encompasses 
all areas of the detect, control, engage paradigm and 1s part of the user interface processing 


in the architecture template. 
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Figure 15. Combat System Enhanced Data Flow Diagram 


Each function is a black box that converts data inputs into outputs. The EDFD 
shows the data flows between functional boundaries and system interfaces. Developing the 
EDFD allows for assigning physical entities to the model to create the architectural flow 


diagram which is used to determine variability within the combat system. 


2. Combat System Architectural Flow Diagram 


The Hatley-Pirbhai AFD in Figure 16 is an evolution of the EDFD with physical 
entities, or architecture modules, describing the combat system as opposed to system 
functions. Functional boundaries on the AFD are maintained utilizing the same architecture 
template used for the EDFD. Arrows between architecture modules in the AFD indicate 


data transfer. 


The AFD follows the detect, control, engage paradigm that 1s the central theme of 
the proposed combat system. Contacts (Ci through Cn) are detected via transmitted and 


received signals from the sensors module, this occurs in the input processing area of the 
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architecture template. These received signals are transformed into contact data, which is 
sent to the system bus / network. The combat system receives remote track data and remote 
engagement orders (REOs) from non-organic sensors and force-planning assets through 
the data links module. This data is in turn transferred to the system bus / network. Both 
data links and the network bus reside in the support functions section of the architecture 


template. 


The output from the bus / network is track data, which inputs to the command and 
control system. The command and control system sends target data to consoles and displays 
as part of the user interface processing area of the architecture template. Additionally, the 
command and control system provides sensor and weapons control for the sensors and fire 
control modules. Since the command and control system handles the core processing for 


the combat system, it occupies the main functions space of the architecture template. 


In order to engage a target, the fire control module also receives weapons 
scheduling data from the consoles and display module. Weapons data is then transferred to 
the weapons (W; through W,) based on the target engagement. This occurs in the output 
processing section of the architecture template. Each of the physical entities, functional 
boundaries, and data transfers, describes the functional combat system developed in the 


EDFD as a physical combat system in the AFD. 
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Figure 16. Combat System Architectural Flow Diagram 





>. Variation Points and Textual Requirements 


Through analyzing the functional and physical constructs of the EDFD and AFD, 
four variation points were identified for further decomposition and component allocation. 
The next step towards developing orthogonal variability models for the combat system is 


to derive variability textual requirements for the following variation points: 


l. Sensors (VP) 

pa HSI/ Console (VP) 
a: Weapons (VP) 

4. Data Links (VP) 


Components, and subsequently variants, are allocated to the variation points with 
explicit textual requirements that allow for greater accuracy in developing orthogonal 


variability models. The variation points provide the top-level components and the variants 
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provide the second level components in the physical hierarchy. The textual requirements 


for the four variation points are listed in Tables | through 4. 


Table 1. | Sensors Variation Point Textual Requirements 


Wevut-letormmerem [he sensors shall have the ability to... 


...conduct volume air search and tracking... 
...and conduct surface search and tracking... 


...and search / track in the electro-optical / infrared spectrum... 


...and provide high-resolution imagery for identification and targeting... 


...and query manned / unmanned aerial systems... 


...and provide passive electromagnetic (EM) wave detection. 





Table 2. HSI/ Console Variation Point Textual Requirements 


Welurlstormaeniag | he console / HSI shall be equipped with... 





Table 3. | Weapons Variation Point Textual Requirements 


WEVurclscesmaeiiiae | he weapons shall have the ability to... 


...target and engage air targets at long range... 
..and target and engage surface targets at long range 


and target and engage air / surface targets a short range... 
...and provide long-range naval surface fire support... 


...and provide supportability for future weapons technology... 
...and provide offensive capability in the EM spectrum. 
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Table 4. | Data Links Variation Point Textual Requirements 


Wevutlstorm@aeriag | he data links shall have the ability to... 


...transfer data with assets within line of sight (LOS)... 


...and transfer data with assets beyond LOS... 


Variant ...and transfer data via satellite... 





4. Allocated Architectural Flow Diagram 


Incorporating the variability textual requirements for variation point allocation 
results in an AFD with allocated components to each variation point. This revised, allocated 
AFD uses SysML notation for the variation points and associated variants listed below 
them. The allocated AFD follows the same architecture template and includes the same 


information transfers between physical entities as the AFD in Figure 17. 


Detect Control Engage 
Contact Shot 
Ci S; 


<<HS|>> 


2.1 Single Console 

2.2 Multiple Console _ 
2.3Single Display 
~ 2.4Multiple Display 
re ae oe deseeennp 


<<Se nsors>> 
3.1 Surface to Air Missile 
3.2 Surface to Surface Missile 


Soe see a "3.3 Gun (Chemical Propellant). 


2 Surface Search Radar 34 Gun (Electrom agnetic) 

SEO; R “3.5DirectedEnersy 

Heee ceteris are en Ces “36—EW  —~— 
CS 


4.1 Terrestrial LoS 
__ 4.2 Terrestrial Beyond LoS (Relay) 
4.3 Satellite 





Remote Remote 
Track Engzazement Oni ars 
Dat (REOs) 


Figure 17. Component Allocation to Architectural Flow Diagram 
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The variants for the sensors variation point are traced back to the 1.0 Sense function 
and 5.0 Assess Engagement function in the EDFD. Each variant for the sensors variation 
point is numbered using the second level components of the physical hierarchy numbering 
convention discussed earlier in the chapter. The variants include air and surface search 
radars, which fulfill the textual requirements of having the ability to conduct search / track 
in the air and surface battle spaces. The electro-optical and infrared integrated sensor 
provides the search and track capability in the electro-optical-infrared (EO-IR) spectrum. 
High-resolution imagery is provided organically by a light detection and ranging (LIDAR) 
sensor and air contact querying services are provided by an IFF antenna. Finally, an 


electronic warfare subsystem allows the combat system to passively detect EM waves. 


The 2.0 Coordinate Mission function is associated with the consoles / HSI variation 
point. There are five variants for this variation point, which are all concerned with the 
human system interface to coordinate the mission within the combat system. The variants 
follow the second level component numbering convention and are unchanged from the 
variant textual requirements. For example, the variant textual requirement of “or multiple 
displays” is represented in the allocated AFD as “2.4 Multiple Display” for the consoles / 


HSI variation point. 


The weapons variation point has different weapon variants that relate to the 3.0 
Engage Target function. Weapon variants include missiles, both surface to air and surface 
to surface, which fulfil the textual requirements of engaging air and surface targets at long 
or short ranges. Engaging air and surface targets at short ranges is satisfied by chemical 
(conventional) propellant and electromagnetic guns. Additionally, electromagnetic 
railguns provide the capability to provide long-range naval surface fire support, meeting 
that textual requirement. Directed energy weapons allow the combat system to coincide 
with the textual requirement of providing supportability for future weapons technology. 
Electronic warfare systems that can engage targets actively or passively provide an 


offensive capability in the EM spectrum. 


The 4.0 Provide Data and Information Services function is accomplished via the 
data links variation point. The variant textual requirements and subsequent variants of 


“terrestrial, line of sight,” “terrestrial, beyond LOS (Relay),” and “satellite,” were derived 
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from the Key Navy Communication Systems outlined in Figure 6.1 in the National 
Academy Press’s ** C4ISR for Future Naval Strike Groups” (National Academy Press 2006, 
152). The data transfer textual requirements and numbering convention correspond with 


the three variants for the data links variation point. 


3; Orthogonal Variability Models 


Developing the enhanced data flow diagram and architectural flow diagram 
provides the process to identify variation points within the combat system. Allocating 
components in the architectural flow diagram via variation point textual requirements 
ensures the associated variants can be traced back to the AFD and EDFD architectures. 
OVMsSs are necessary for modeling the variation points, their associated variants, packaged 
variants, alternative choices, and dependencies. This forms the construct of the combat 
system engineering product line. All OVMs utilize Halmans and Pohl notation for each of 
following variation points identified in the variability textual requirements and associated 


allocated AFD. 


OVMs for each of the four variation points show the alternative choices of variants 
as well as variability dependencies. The variants utilized in the product line are determined 
by the packaged combat system variant (SUW / IRS, cruise missile defense, or TBMD + 
cruise missile defense) chosen by the customer. Each of the four variation points and the 
packaged combat system variants are combined to produce the product line OVM. This 
product line OVM details constraint dependencies for variants and variation points. It 
provides a common model for determining which variation points and variants are required 


for each packaged variant constituting the combat system product line. 


The OVM for the sensors variation point is shown in Figure 18. This variation point 
has six alternative choices that are all optional variants. As described previously in Figure 
14, the dashed lines between the sensors variation point and each variant represent the 
“optional” variability dependency. The solid arch denotes each of the variants as an 
alternative choice for this variation point. These variants were identified from the variation 
point textual requirements and allocated to the sensors variation point in the allocated AFD. 


Air search radar, surface search radar, EO-IR, LIDAR, IFF, and EW are all optional 


44 


variants for the sensors variation point. These variants supply the capability for the 1.0 
Sense and 5.0 Assess Engagement functions of the combat system. The variants also allow 


for a common interface for the sensors variation point in the product line. 





V 


Surface Search 


Air Search Radar LiDAR IFF 


Radar 





Figure 18. Sensors Variation Point Orthogonal Variability Model 


The HSI / consoles variation point offers five optional variants as alternative 
choices that are focused on the consoles and displays for the combat system. The number 
of consoles and displays depend on the tier of combat system represented as a packaged 
variant. These dependencies are described later in the combat system product line OVM. 
Figure 19 shows the optional variability dependencies amongst alternative choices for the 
HSI / consoles variation point and its variants. This variation point is mapped to the 2.0 
Coordinate Mission NS the variants were generated from the variation point textual 
requirements. The variants allow for numerous configurations based on the combat system 


tier chosen. 
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Figure 19. Weapons Variation Point Orthogonal Variability Model 


The variants for the weapons variation point in Figure 20 are directly related to the 
combat system’s ability to perform the 3.0 Engage function. All of the alternative choices 
are optional variants; however, constraint dependencies in the product line variant 
determine which variants to use based on the required warfare area capabilities for each of 
the three combat system tiers. These warfare area capabilities are associated with the 
variation point textual requirements. Surface warfare engagement capabilities differ from 
theater ballistic missile defense and cruise missile defense capabilities. Furthermore, 
additional variants provide the flexibility to incorporate future weapons such as 
electromagnetic guns and directed energy weapons. Constraint dependencies for the 
combat system tiers in relation to the weapons variation point are discussed in greater detail 


in the product line OVM description. 
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Figure 20. Weapons Variation Point Orthogonal Variability Model 
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The data links variation point and its three associated variants relate to function 4.0 
Provide Data / Information Services. Transmitting and receiving data, external of the 
combat system, requires wireless data transfer. These data link variants are optional 
variants, as shown in Figure 21; however, they are required through constraint 
dependencies for each of the three combat system tiers. The capability line of sight, beyond 
line of sight, and satellite data links provide what is required for the “control” action of the 


detect, control, engage paradigm represented in this combat system model. 
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Figure 21. Data Links Variation Point Orthogonal Variability Model 


The product line orthogonal variability model, Figure 22, describes the three tiers 
of combat systems that are being proposed for the product line. This OVM introduces the 
concept of packaged variants to reduce complexity of the model when representing each 
of the tiers. The variation point of “Combat System Package” includes three variants, SUW 
/ ISR (1st tier), cruise missile defense (2nd tier), and TBMD + cruise missile defense (3rd 
tier). These variants are all optional, packaged variants that can be chosen based on the 


customer’s needs. 


Variation points and associated variants for sensors, HSI, weapons, and data links 
are also included in the product line OVM. These variation points and variants remain 
unchanged from the individual variation point OVMs detailed previously. In addition to 


the combat system package variation point and packaged variants, the product line OVM 


AT 


shows constraint dependencies between variation points and variants. The constraint 
dependencies follow the same Halmans and Pohl notation presented earlier in Figure 14. 
The combat system package variation point requires the sensors, HSI, weapons, and data 
links variation points. The packaged variants require or exclude different variants 
depending on the capabilities of the combat system tier. These variant requirements and 
exclusions parallel the detect, control, engage paradigm of the combat system and are 


discussed below for each of the three tiers. 


a. SUW/ISR (1" Tier) Packaged Variant 


The proposed SUW / ISR combat system package is intended for small surface 
combatants that could be manned or unmanned. This packaged variant includes constraint 
dependencies that require the surface search radar and EO-IR sensor from the sensors 
variation point. These sensors are necessary to fulfil the SUW and ISR missions that may 
include engagement of surface targets as well as surveillance of surface targets. Since this 
packaged variant does not include the ability to engage air targets, constraint dependencies 
excluding air search radar and IFF are integrated into the OVM. The EW sensor is also 
excluded from the SUW / ISR packaged variant. LIDAR is an available optional variant, 


although, it does not have any constraint dependencies. 


If the surface ship is to be manned, the SUW / ISR packaged variant requires at 
least a single console and single display variant, to have the human system interface 
necessary to control the combat system. Multiple console and multiple display variants are 
options but not requirements. Display sizes can be selected based on to the customer’s 
needs. Additionally, all data link variants are required for this packaged variant as 


previously discussed. 


The only required variant for the weapons variation point is a chemical propellant 
gun, which is necessary to engage targets. This packaged variant excludes the surface to 
air missile variant due to the first tier’s intended surface warfare capability. Similarly, the 
electromagnetic gun, directed energy, and EW system variants are excluded from the SUW 
/ ISR packaged variant. The surface-to-surface missile variant is an optional variant since 


it has the capability to engage surface targets. 
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b. Cruise Missile Defense (2 Tier) Packaged Variant 


The 2nd tier of the combat system product line is designed as a system focused on 
cruise missile defense capability. It is defined by the cruise missile defense packaged 
variant and its constraint dependencies. The cruise missile defense packaged variant is 
envisioned for use on future guided missile frigate (FFGX), aircraft carrier (CVN), and 
amphibious assault ships. Each of the required variants is focused on the cruise missile 
defense mission. The 2nd tier packaged variant has constraint dependencies that require 
both air search and surface search radars, necessary to detect and engage targets. There is 
also an EW variant required, part of the sensors and weapons variation point, for detecting 
electromagnetic waves, as well as providing offensive capability in the EM spectrum. The 
required IFF variant is needed to assist with hostile, friendly, or unknown determination of 
a target. EO-IR and LIDAR variants are optional sensors but are not required for the cruise 


missile defense packaged variant. 


Due to the complexity and scale of cruise missile defense scenarios, the human 
system interface for this packaged variant requires multiple consoles and multiple displays. 
Single consoles and single displays are options for the HSI variation point, allowing for 
greater customization. As with the Ist tier packaged variant, display size is selected based 


on the customer’s needs and all three data links are required variants. 


The cruise missile defense packaged variant requires surface to air missiles in order 
to engage targets. Surface to surface missiles, chemical propellant and electromagnetic 
guns, and directed energy weapons are all optional variants that can be added to this 
packaged variant; however, they are not required. Focused constraint dependencies allow 
each packaged variant to have the necessary components required for the proposed mission 
capability. The additional optional variants without constraint dependencies allow for mass 


customization for specific combat system applications. 


C. Theater Ballistic Missile Defense + Cruise Missile Defense (3 Tier) 
Packaged Variant 


The addition of theater ballistic missile defense capability to the cruise missile 


defense packaged variant results in the 3rd tier packaged variant. This packaged variant is 
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intended for future guided missile destroyer and guide missile cruiser platforms tasked with 
ballistic missile defense in addition to cruise missile defense missions. Constraint 
dependencies remain the same, as shown in Figure 22, since the physical components of 
the product line are similar. For example, the power requirements for the necessary ranges 
and target resolution for the air search radar may be greater for the TBMD packaged variant 
(3rd Tier) than the cruise missile defense (2nd Tier) packaged variant. However, this 
hardware upgrade does not affect the orthogonal variability model because the TBMD 
packaged variant requires an air search radar, the OVM does not specify the air search 


radar. 


Similarly, the TBMD packaged variant also requires surface to air missiles to 
engage ballistic targets. The 3rd tier packaged variant surface to air missiles may require 
different capabilities than the 2nd tier packaged variant missiles, such as greater ranges, 
kill mechanisms, and probability of kill (Px) requirements. Again, the hardware capabilities 
do not affect the constraint dependencies in the product line OVM. The OVM and 
constraint dependencies show the required variants for the 3rd tier packaged variant which 


happen to be the same constraint dependencies as the 2nd tier packaged variant. 


The product line approach to combat system design is facilitated with the product 
line orthogonal variability model. The OVM construct with packaged variants, variation 
point, and variant constraint dependencies provides a method of developing different 
products with different capabilities. It allows for variant options within the packaged 
variants themselves. This results in the ability to create a combat system product line from 
variation points and variants while ensuring integrity of the design due to the underlying 


system architecture. 
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Figure 22. Combat System Product Line Orthogonal Variability Model 
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D. ANALYSIS 
1. System Constructive Product Line Investment Model 


The system level Constructive Product Line Investment Model utilizes parametric 
model inputs related to engineering product lines for various system types. The outputs of 
the model describe the life cycle savings of product reuse and return on investment. 
Originally, standard COPLIMO was a detailed model for software product lines to quantify 
the benefit of reusing source computer code (Boehm, Barry, et al., 2004, 8). It was also 
extended for software quality as a quality-base constructive product line investment model 
(qCOPLIMO) (Hoh, Peter, et al. 2006, 86). The software model was later modified for 
systems-level product lines on the System Engineering Research Center (SERC) Valuing 
Flexibility research (SERC RT18, 2012). Detailed inputs for software were replaced by 
aggregate factors for both hardware and software subsystems (SERC RT18, 2012). 
COPLIMO was demonstrated for representative DoD system types using empirical system 
maintenance data (Boehm, Lane, and Madachy 2011, 4). That demonstration model was 


further generalized as System COPLIMO and applied in this research. 


Inputs for the System COPLIMO include: 


l. System Costs 

Zi Product Line Percentages 

a Relative Cost of Reuse Percentages 
4. Investment Cost 


These inputs will be applied to each of the three, combat system product line 
packaged variants (proposed combat system tiers). System costs are defined by four 
parametric inputs, average product development cost, ownership time, annual change cost 
(percentage of development cost), and annual interest rate. The SUW / ISR (1st Tier), 
cruise missile defense (2nd Tier), and TBMD + cruise missile defense (3rd Tier) packaged 
variants each have estimated average product development costs. These estimated costs are 
based on current combat system average unit costs with similar capabilities to the three 


2 


tiers proposed by the author. The Ist Tier cost is $10 million per system, the 2nd Tier is 
$147 million per system based on FY17 Aegis Weapon System cost data, and the 3rd tier 
is $322 million per system based on FY17 Aegis Weapon System and FY17 Advanced 
Missile Defense Radar (AMDR) cost data (Department of Defense Fiscal Year (FY) 2017 
President’s Budget Submission 2016, 127-138). 


For the purposes of this demonstrated cost model, the average unit costs do not 
include missile or ammunition load outs. Ownership time is defined as 40 years, which 1s 
an estimated average service life of a surface combatant, not dependent on system type. 
Annual change cost is set at 10 percent, which is an estimate required by COPLIMO. 
Annual interest rate is 2.625 percent (Bureau of the Fiscal Service, U.S. Department of the 
Treasury 2018) in accordance with the Department of Defense Financial Management 


Regulation (Department of Defense Financial Management Regulation 2018, 119). 


Product line percentages for the three packaged variants were determined using 
countable system components (variants), identified from Figure 22, that are mission 
unique, adapted, or reused across products. For the purpose of System COPLIMO, the 
packaged variants are parametric inputs. The 20 total variants are organized by variation 
point listed in Table 5 with rationale for their classification of mission unique, adapted, or 


reused across products. 


Table 5. Product Line Variant Classification 


Variation Point: Sensors 


Product Line Variant Rationale 
Classification 


Adapted Air Search Power, beam forming, and search / track 
Radar functions different for 2nd and 3rd tier packaged 


variants. 
different for 2nd and 3rd tier packaged variants. 
Physical size and capabilities of sensor can be 
Radar used for Ist, 2nd, and 3rd tier packaged variants. 


Reused IFF Hardware and interfaces are the same for 2nd 
and 3rd tier packaged variants. 
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Variation Point: Sensors 
Variation Point: HSI 


Classification 
Console packaged variants. 
Console 
packaged variants. 
Display 
by customer. 


Variation Point: Data Links 


Product Line Variant Rationale 
Classification 
Reused Terrestrial Data links standardized across U.S. and NATO 


LOS platforms, therefore they are also common 
across Ist, 2nd, and 3rd tier packaged variants. 


Reused Terrestrial See Terrestrial LOS justification. 
Beyond LOS 


See Terrestrial LOS justification. 


Variation Point: Weapons 


Classification 
Missile 2nd and 3rd tiers. 


Mission Unique Surface to Ranges and size of missile different for Ist, 2nd 
Surface and 3rd tiers based on mission and ship size. 
Missile 
Mission Unique Gun Power and size constraints dependent on ship 
Electro- size and cost for 2nd and 3rd tiers. 
Magnetic 
Mission Unique Directed See Gun, Electro-Magnetic justification. 
Energy 
Weapon 
Adapted Gun Size and range of gun dependent on ship size 




















Chemical and cost for Ist, 2nd, and 3rd tiers. 
Propellant 


Adapted EW Power and physical size requirements may be 
different for 2nd and 3rd tier packaged variants. 
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Tables 6 through 8 provide a summary of the variants mission unique, adapted, and 
reused in each of the three packaged variants of product line, represented as product line 


percentage inputs for the System COPLIMO. 


Table 6. — Ist Tier Packaged Variant Product Line Percentages 


1st Tier Packaged Variant (13 Total Possible Components) 


System Product Line Percentage 
Component Type 


Adapted 





Table 7. 2nd Tier Packaged Variant Product Line Percentages 


25 % 





Table 8. 3rd Tier Packaged Variant Product Line Percentages 





The relative cost of reuse percentages input field includes percentage costs for both 
adapted and reused variants. These percentages are 40% for adapted variants and 5% for 
reused variants, which is consistent with System COPLIMO inputs. The investment cost is 
the relative cost of developing for product line flexibility via reuse. This value is 1.7, which 


represents an additional 70% investment effort to develop a product line, as opposed to a 
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non-product line system (Boehm, Lane, and Madachy 2011, 14). The COPLIMO 


parametric inputs for the three product line tiers are summarized in Tables 9 through 11. 


Table 9. — Ist Tier System COPLIMO Input Summary 


System COPLIMO Input Summary (1st Tier Packaged Variant) 


System Costs 
Development Cost 
Annual Change Cost 10 % Estimate 
(% of Development 
Cost) 


ost 
Bureau of the Fiscal Service, U.S. 
Department of the Treasury 2018 
Product Line Percentages 


Adapted From Table 6 
From Table 6 


Relative Cost of Reuse (%) 


COPLIMO default 
for Reused 
Investment Cost 


Relative Cost of ed COPLIMO default 
Developing for PL 
Flexibility via Reuse 


Table 10. 2nd Tier System COPLIMO Input Summary 





System COPLIMO Input Summary (2nd Tier Packaged Variant) 


System Costs 


Average Product $147M Department of Defense Fiscal Year (FY) 
Development Cost 2017 President’s Budget Submission 2016, 
127-138 


Annual Change Cost 
Ownership Time DoD Selected Acquisition Report 2015, 48 


Interest Rate 2.625 % Bureau of the Fiscal Service, U.S. 
Department of the Treasury 2018 
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System COPLIMO Input Summary (2nd Tier Packaged Variant) 
Product Line Percentages 


From Table 7 
Adapted From Table 7 
From Table 7 


Relative Cost of Reuse 


Reuse for Adapted 
Reuse for Reused 
Investment Cost 
Relative Cost of COPLIMO default 


Developing for PL 
Flexibility via Reuse 





Table 11. 3rd Tier System COPLIMO Input Summary 


System COPLIMO Input Summary (3rd Tier Packaged Variant) 
Value 
System Costs 
Average Product Department of Defense Fiscal Year (FY) 
Development Cost 2017 President’s Budget Submission 2016, 
127-138 


Annual Change Cost 
Ownership Time DoD Selected Acquisition Report 2015, 48 


Interest Rate Bureau of the Fiscal Service, U.S. 
Department of the Treasury 2018 


Product Line Percentages 


Mission Unique From Table 8 
Adapted From Table 8 
Reused From Table 8 


Relative Cost of Reuse 


Reuse for Adapted 
5 % COPLIMO default 
Reuse for Reused 


Investment Cost 
Relative Cost of COPLIMO default 
Developing for PL 
Flexibility via Reuse 
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Outputs for the System COPLIMO include: 


l. Development Cost 

2: Ownership Cost 

3 Cumulative Product Line Cost 

4. Product Line Flexibility Investment 
3. Product Line Effort Savings 

6, Return on Investment 


The System COPLIMO tool used in this research was developed by Madachy 
(Madachy 2018) as an adaption of the system-level product line flexibility tool 
demonstrated for select DoD domains (SERC RT18, 2012). The parametric input and 
output values are displayed in Figures 23 through 25 for System COMPLIMO applied to 
each of the combat system product line packaged variants (three tiers). The return on 
investment output provides a metric for determining the cost benefit of a product line 
engineering approach. ROI is defined as the net effort savings (PL Effort Savings), divided 
by the product line (PL) investment, shown in Equation 1. Initial results using the empirical 
cost data and COPLIMO defaults for relative cost of reuse and PL development, suggest a 
strong ROI as the number of products produced increases. All three cases demonstrate the 


same ROI due to constancy of the relative cost inputs. 


ROI = PL Effort Savings / PL Investment (1) 
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System COPLIMO 


System Costs 
Average Product Development Cost (Burdened $M) 10 Ownership Time (Years) 40 
Annual Change Cost (% of Development Cost) 10 Interest Rate (Annual %) 2.6 


Product Line Percentages Relative Costs of Reuse (%) 


Unique% 8 Relative Cost of Reuse for Adapted 40 
Adapted% 15 Relative Cost of Reuse for Reused 5 


Reused % 77 


Investment Cost 
Relative Cost of Developing for PL Flexibility via Reuse 1.7 


Calculate Monte Carlo Off <© 


Results 
# of Products 4 2 3 4 5 6 7 Return on Investment 
Development Cost ($M) $14.2 |$5.4 |$5.4 1$5.4 |1$5.4 |$5.4 |$5.4 
Ownership Cost ($M) $56.8 |$21.4/$21.4 |$21.4 |$21.4 |$21.4 |$21.4 


Cum. PL Cost ($M) $71.0 |$97.8/$124.5/$151.2/$178.0/$204.8|$231.5 

PL Flexibility Investment ($M)|$4.2 {$0 {$0 $0 $0 $0 $0 

PL Effort Savings ($21.0)|$2.2 |$25.5 |$48.8 |$72.0 |$95.2 |$118.5 

Return on Investment -5.00 0.54 6.07 |11.61 |17.14 |22.68 |28.21 ia af 
eae — 


-5.0 || 0.5 || 6.1 |) 11.6 |] 17.1 || 22.7 || 28.2 
1 2 3 S 5 6 7 


Product # 


Figure 23. System COPLIMO for SUW / ISR (1st Tier) Packaged 
Variant. Source: Madachy (2018). 
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System COPLIMO 


System Costs 
Average Product Development Cost (Burdened $M) 147 Ownership Time (Years) 40 
Annual Change Cost (% of Development Cost) 10 Interest Rate (Annual %) 2.6 


Product Line Percentages Relative Costs of Reuse (%) 


Unique% 20 Relative Cost of Reuse for Adapted 40 
Adapted % 25 Relative Cost of Reuse for Reused 5 


Reused% 55 


Investment Cost 
Relative Cost of Developing for PL Flexibility via Reuse 1.7 


Calculate Monte Carlo Off <© 






Results 
# of Products 4 2 3 4 5 6 _ Return on Investment 
Development Cost ($M) $208.7 [$78.6 $78.6 [$786 ($78.6 [$78.6 
Ownership Cost ($M) $835.0 ($314.6 |$314.6 |$314.6 |$314.6 |$314.6 |$314.6 
Cum. PL Cost ($M) $1 ,043.7 |$1 ,436.9/$1,830.1|$2,223.4 eee $3,403.0 


PL Flexibility Investment ($6M)|$61.7 |$0 $0 $0 
PL Effort Savings ($308.7) |$33.1 $374.9 |$716.6 |$1,058.4/$1,400.2/$1,742.0 
Return on Investment -5.00 0.54 6.07 11.61 : i ; fa ia 


-5.0 || 0.5 || 6.1 || 11.6 || 17.1 || 22.7 || 28.2 
1 2 3 o 5 6 7 





Product # 


Figure 24. System COPLIMO for Cruise Missile Defense (2nd Tier) 
Packaged Variant. Source: Madachy (2018). 
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System COPLIMO 


System Costs 
Average Product Development Cost (Burdened $M) 322 Ownership Time (Years) 40 


Annual Change Cost (% of Development Cost) 10 Interest Rate (Annual %) 2.6 


Product Line Percentages Relative Costs of Reuse (%) 


Unique% 20 Relative Cost of Reuse for Adapted 40 
Adapted % 25 Relative Cost of Reuse for Reused 5 


Reused% 55 


Investment Cost 
Relative Cost of Developing for PL Flexibility via Reuse 1.7 


Calculate Monte Carlo Off <> 


Results 
# of Products 4 2 3 4 5 6 7 Return on Investment 
Development Cost ($M) $457.2 1$172.3 |$172.3 |$172.3 ($172.3 {$172.3 |$172.3 
Ownership Cost ($M) $1,829.01$689.1 {$689.1 |$689.1 |$689.1 ($689.1 /|$689.1 


Cum. PL Cost ($M) $2,286.2|$3,147.5|$4,008.9/$4,870.2|$5,731 .6|$6,593.0/$7 454.3 

PL Flexibility Investment ($M)|$135.2 |$0 $0 $0 $0 $0 $0 

PL Effort Savings ($676.2) $72.5 |$821.1 |$1,569.8/$2,318.4/$3,067.0/$3,815.7 

Return on Investment -5.00 0.54 6.07 11.61 17.14 |22.68 |28.21 Ey Fl 
al a_i 


-5.0 || 0.5 || 6.1 || 11.6 || 17.1 || 22.7 || 28.2 
1 2 3 4 5 6 7 


Product # 


Figure 25. System COPLIMO for TBMD + Cruise Missile Defense (3rd 
Tier) Packaged Variant. Source: Madachy (2018). 


61 


E. SUMMARY 


The methodology presented in this chapter provides a high-level structure and 
arrangement in which future combat system product line design can be modeled after. 
System design starts with a functional architecture that captures the detect, control, engage 
paradigm of target engagement in a combat system. This functional architecture is 
presented as an EDFD. The functional architecture is translated into a physical architecture 
based on system functions and the physical entities that perform those functions. This 
physical architecture is presented as an AFD. Hatley—Pirbhai modeling and the associated 
architecture template offer the necessary entities to display input processing, output 
processing, main functions or core processing, user interface processing, and support 
functions within the combat system. Analysis of the EDFD and AFD provides the means 


for identifying variation points within the combat system. 


Once variation points are identified, variation point textual requirements are 
applied to each variation point. These textual requirements are translated into variants that 
can be chosen by the customer to mass customize that product line, subject to variant 
options and constraint dependencies. Additional variation point textual requirements can 
be added in the future, which allows for new technology insertion into existing combat 
systems. As technology advances, the product line can adapt to the future combat system 


needs. 


Orthogonal variability modeling provides the means of displaying alternative 
variant choices as well as constraint dependencies. Generating package variants allows for 
an efficient method of describing complex variant, variation point, and constraint 
dependency combinations. Finally, the product line OVM furnishes the variants in a 
manner that facilitates enumeration of mission unique, adapted, and reused variants 
necessary for the System COMPLIMO. The cost model provides a trade space for 
determining initial investment and future return on investment with respect to product line 


systems versus non-product line systems with associated reuse processes. 
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IV. CONCLUSION 


The disaggregated nature of current U.S. Navy combat systems 1s not optimal from 
a technical design nor cost perspective throughout the system’s life cycle. Employing a 
product line engineering approach to future combat system design is beneficial for both the 
combat system developer as well as the customer. Product line engineering concepts such 
as building once and the planned reuse of system components, helps the Navy achieve the 
overarching strategic guidance of the CNO as well as technical guidance from NSWC. The 


research questions presented in Chapter I are answered: 


l. Can Product Line Engineering approaches be used to develop a common 
system architecture design for future Navy combat systems instead of 


using unique, platform specific combat system suites? 


The literature review in Chapter II discusses the concepts of product line 
engineering, system architecture, open systems and open architecture. A review of current 
surface combatant combat systems, both U.S. and European, provides the foundation for 
functional and physical analysis of combat systems. This review also reinforces the notion 
that current U.S. Navy combat system suites are ship-class dependent. The Aegis Combat 
System, Ship Self Defense System, and Component Based Total Ship System were all 
developed for specific missions and platforms without considering the need for 
commonality between systems. European combat system from Terma, SAAB, and Thales 
are reviewed to provide the reader with examples and context of different combat system 
product lines. These product lines are Terma’s C-Series, SAAB’s 9LV, and TACTICOS 
from Thales. Functional analysis of all of the combat systems results in the proposed 
combat system function of sense, coordinate mission, engage target, provide data / 
information services, and assess engagement. These functions are used to develop the 
system architecture in Chapter III utilizing concepts of Open Architecture and Product Line 


Engineering. 


Z: What common functional and physical features as part of the architecture 


would be important aspects of developing a combat systems product line? 
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Chapter III introduces the methodology, approach, and example for the proposed 
combat system product line. In order to scope the capabilities of the combat system, three 
combat system tiers are utilized, SUW / ISR capable (1st Tier), cruise missile defense 
capable (2nd Tier), and theater ballistic missile defense and cruise missile defense capable 
(3rd Tier). The system architecture starts with Hatley-Pirbhai modeling and the associated 
architecture template. An enhanced data flow diagram and related architectural flow 
diagram describe the functional and physical behavior of the combat system. Each system 
architecture diagram maintains the detect, control, engage paradigm as the central premise 


of the combat system architecture, both functional and physical. 


The AFD provides the structure for variation point identification necessary for 
orthogonal variability modeling in the product line construct. Component allocation to the 
AFD via textual requirements, revise the AFD to represent physical components that 
provide the variants for each variation point in the product line. Four variations points are 
identified, sensors, HSI / consoles, weapons, and data links. The variation points and 
associated variants are presented as OVMs, showing alternative choices for each variation 
point. The variation point OVMs are consolidated into a product line OVM with the 
addition of packaged variants for each of the three combat system tiers as well as constraint 
dependencies. These constraint dependencies demonstrate the feasible combinations of 


packaged variants, variation points, and variants for the combat system product line. 


oF How can a product line strategy economic analysis be conducted utilizing 
a system level parametric model for cost and return on investment analysis 


of product options for the combat system? 


The System COPLIMO model analysis uses inputs based on actual cost data from 
current U.S. Navy combat systems with similar capabilities to the three product line tiers 
to provide a calibrated estimate of ROI, by product , for a product line versus non-product 
line approach. The orthogonal variability models are used to identify mission-unique, 
adapted, and reused system components (variants) across products. The System 
COMPLIMO uses these components’ percentages as inputs for the cost model. The cost 


model results are valid for the case study percentages of unique, adapted, and reused system 
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components, however different architectures and thus variability models, result in different 


ROIs and cost savings over time. 


A. RECOMMENDATIONS 


The isomorphic mapping of software product line engineering concepts to combat 
system product line engineering results in a systematic methodology that should be 
followed during the earliest stages of combat system design. By applying the methodology 
demonstrated in this thesis as shown in Figure 26, future combat system design can identify 
common architectural components, develop a tailored engineering product line, and 


conduct product line economic analysis utilizing System COPLIMO. 
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Figure 26. Combat System Product Line Engineering Methodology 


Applying the engineering product line methodology to combat system architecture 
design and development should optimally happen at the earliest stage of design. High-level 
system architecture design for future U.S. Navy combat systems should focus on the 


product line, instead of platform specific combat systems. The three combat system tiers 
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that were proposed were not all-inclusive and should only be used as a means of 


demonstrating the product line engineering methodology. 


B. FUTURE WORK 


The scope of combat system design in this thesis was limited to SUW, cruise missile 
defense, and cruise missile + TBMD. Future work can be conducted to develop engineering 
product lines for additional warfare areas such as anti-submarine warfare, electronic 
warfare, cyber warfare, and others. Similar methodology can be applied to combat system 
design for applications not specific to the Surface Navy, such as integrated air and missile 


defense (I[AMD) systems, ground vehicles, undersea vehicles, and aircraft. 


Two levels of decomposition were introduced for the functional and physical 
architectures of the proposed combat system. This hierarchy can be further decomposed 
into third and fourth levels to provide greater level of detail at the subsystem level. 
Subsystem decomposition would provide additional variation points and associated 
variants that could be included in the orthogonal variability models to deliver more product 
line options while also exploring new constraint dependencies. These levels of detail also 
provide greater insight into setting input values for System COPLIMO, with expected 


greater precision in the results. 


Furthermore, the enhanced data flow diagram and architectural flow diagrams can 
be tested in simulation software, following the detect, control, engage paradigm for 
different scenarios. Data can be generated from the simulations to validate the proposed 
system architecture. This can be used for iterative design on the system architecture, which 
may influence the variation points and variants for the combat system product line. The 
System COPLIMO analyses would also need to be revised for variation points and variants 


that were changed due to simulation testing on the system architecture. 
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